Call or Charging Data Records (CDR) collected from network elements are rated and charged in appropriate components of a business support system (BSS). While being processed in rating these records are enriched with subscriber specific information and also information about the services used, the charges calculated and the discounts applied. After rating and charging the records need to be stored in operational data storage before they are invoiced at the end of the billing period, usually a month.
During the invoicing process all CDRs applicable to the billing time frame are retrieved from persistent storage. If promotions and billing time discounts are applied to CDRs during this process, the CDR gets enriched with promotion and discount information and stored back again.
The rated and discounted records are also visible from customer care and self-care components.
CDRs collect all information related to the usage of one more services during the call and the associated pricing and discounting. For this reason CDRs are natively structured as trees with branches for various services used and all pricing components.
CDRs have to be made persistent for several reasons. On one hand they have to be available for the billing and customer care. On the other hand they have to be forwarded to data analytics components for reporting issues.
A typical distribution of storage demands is 5-10% for customer care data, 10-20% for bill images and the remaining 75% for usage data records, which are the rated and charged call detail records.
Current storage implementations foresee to store the CDRs in a relational database system. As a first step the storage model reflects the tree structure in a normalized relational structure by designing appropriate tables and relationships. In a second step this normalized model is de-normalized for performance reasons leading to information duplication.
Today's telecommunication services have evolved from the plain usage of telephony towards high complex diverse solutions generating a high volume of call data. In order to assure the revenue of an operator requires that potentially anonymized call detail information has to be made persistent over a long period.
BSS systems need to tackle the various issues caused by huge data volume in order to support the different business processes with sufficient performance and latency. This does not only impose requirements on the application software but also on the hardware components participating in this process.
The basic storage concepts for operational call data storage described above lead to various problems:                High storage consumption due the large number of CDRs and the large size of a single CDR due to the high number of CDR information attributes. The storage size per CDR increases with the complexity of business information stored per call. The de-normalization increases the storage size due to the fact that redundant information needs to be made persistent        Classic de-normalization solutions are not sufficient to solve performance and latency issues for today's huge amount of CDRs and the high storage size.        De-normalization leads to consistency issues if updates are performed e.g. during the billing process.        
Operators need to spend significant resources to fulfill the needs of operational CDR data storage for their billing systems. An important cost driver is the huge amount of high performing storage space which has to be provided.